Dieser Audiobeitrag wird von der Universität Erlangen-Nürnberg präsentiert.

Darf ich einmal in die Runde fragen, wer kennt Plohnen bereits?

So, relativ wenige. Ich möchte einfach heute mal Plohnen präsentieren und warum ich bei Plohnen irgendwann hingeblieben bin.

Erstmal kurz, wer bin ich? Ich bin im Moment der Referatsleiter für Internetdienste an der LMU München.

Ich habe dort August 2012 angefangen, habe vorher an der Bundeswehruniversität in München sehr viel mit CMS gemacht.

Ich habe selber Informatik studiert, bin 2004 in eine Auswahlgruppe reingekommen, die das zentrale Kontenmanagementsystem für die Bundeswehruniversität auswählen sollte.

Was ich sehr interessant daran fand, dass wir damals gesagt haben, wir gehen nicht nach dem Prinzip, wir nehmen das, was irgendjemand kennt, sondern wir machen eine saubere Anforderungsanalyse und schauen uns dann ganz präzise die Systeme an.

Wir haben uns viele Systeme angeschaut, insgesamt waren es, Papiermäßig, wo wir durchgegangen sind, 1200 Kontenmanagementsysteme.

Zum Schluss sind wir hingeblieben bei Plohnen, weil das genau unsere Sachen erfüllt hat.

Ich habe mich seit 2004 in Plohnen eingearbeitet, seit 2007 bin ich in der Community aktiv, seit 2010 habe ich mich dann selber bei den internationalen Konferenzen immer beteiligt.

Seit 2012, als ich das Militär verlassen habe, durfte ich dann auch selber Codebeiträge in Plohnen einbinden, weil ich vorher aus ein paar juristischen Gründen das nicht durfte.

Seit Oktober 2013 bin ich im Plohnen Foundation Board of Directors, das heißt der Holding oben drüber, der die Quellcode-Rechte an Plohnen hält.

Ja, wenn wir aus meiner Perspektive nochmal gehen, was war 2004 so in etwa die Idee, ranzugehen?

Klar, irgendwann ist man erstmal ganz naiv und sagt, ja wir wollen das beste Kontenmanagementsystem, aber welches ist das beste Kontenmanagementsystem?

Wie gesagt, es ist eine ganz naive Frage, weil wir ganz schnell merken, well, it depends.

Es ist immer abhängig davon, in was schönem Umfeld man sich bewegt.

Und es basiert wirklich auf den Anforderungen, die man hat, an der Zielgruppe, an der man sich orientiert, an den Kommunikationskandidälen, die man damit bedienen möchte, an der erwarteten User Experience,

aber auch an der eigenen Infrastruktur, die man zur Verfügung hat, kann ich dort überhaupt jedes System betreiben?

Wie ist es mit Zeit- und Terminvorgaben? Manchmal muss etwas schnell gehen, manchmal hat man ein bisschen Zeit.

Geld, Kosten spielen natürlich auch immer eine Sache. Und wie viel Personal hat man?

Na ja, wenn man sich mal Unis oder öffentliche Einrichtungen allgemein anschaut, kann man sagen, wir haben vielleicht nicht immer 100% die gleichen Anforderungen, aber wir haben relativ ähnliche Rahmenbedingungen.

Wir haben Compliance-Vorgaben, wir müssen uns an Barrierefreiheit halten. Webseiten öffentlicher Einrichtungen müssen barrierefrei sein.

Ja, IT-Sicherheit, BSI Grundschutz, es sind Standards, die müssen wir erfüllen.

Es gibt Datenschutz-Vorgaben, an die wir uns halten müssen. Gut, es gibt dann immer noch wieder einrichtungsspezifische Vorgaben.

Aber es sind so Sachen, die halt ein bisschen immer mit zusammenkommen.

Das andere, Universitäten, egal wie man es sagt, man hat immer begrenzte Ressourcen. Als wir es damals ausgewählt haben, war uns klar, es gibt keine Stelle für den Betrieb des CMS.

Das heißt, es muss ein CMS sein, was auch ohne Aufsicht laufen kann, sicher laufen kann. Und das waren so ein paar der Sachen.

Und wir hatten damals genau noch, als wir die Entscheidung getroffen hatten, drei Monate Zeit das System einzuführen. Und das hat problemlos geklappt.

Ja, aber wenn man nochmal ganz kurz zurückgeht, was ist denn der Kerngedanke, wenn man rangeht? Ist es nach einem richtigen CMS?

Es geht nicht um die Technik hintendran. Die IT ist nur der Dienstleister.

Die Leute, die den Inhalt reinbringen, das sind die entscheidenden Leute. Und der Content ist das, was du den Leuten nach außen präsentieren musst.

Das heißt, der Nutzer steht im Fokus, den Administrator, ja, den muss man auch fragen, was er haben möchte.

Aber es geht trotzdem darum, dass wir den Redakteur, der, der die Inhalte reinbringt, erreichen mit dem System.

Weil nur, wenn der bereit ist, die Inhalte auch zu pflegen, und zwar auch vom System animiert wird, da Sachen zu pflegen, dass die Sachen aktuell gehalten werden, dass es einfach ist für ihn.

Erst dann erreiche ich dieses Ziel, nämlich einen guten Auftritt nach außen zu machen.

Ja, im Prinzip kann man sagen, Content Management ist keine Frage der Technik. Alle CMS-Systeme basieren auf Turing-vollständigen Systemen.

Das heißt, ich kann grundsätzlich alles damit umsetzen.

Es ist aber nicht eine Frage des Möglichen, sondern der Effizienz. Schaffe ich es in der Zeit, schaffe ich es mit den Ressourcen und Hilfsmitteln, die ich zur Verfügung habe.

Ja, gut, wie geht man jetzt genau an so eine Evaluation ran? Meistens schaut man sich mal so allgemeine Quellen an, wo man Sachen findet.

Die Real Story Group hat immer eine sehr gute Übersicht über die aktuellen Technologie-Bereiche.

Man schaut sich andere Studien an, Gardner zum Beispiel, gibt es auch einen netten Abschnitt über Plone.

Der Idelavay-Report für NGOs oder auch für öffentliche Einrichtungen ist sehr interessant.

Der Open Source CMS Marketer-Report von Stonewater, von Content Manager gab es mal einen relativ netten Vergleich der Systeme.

Man schaut sich die Sachen ein bisschen genauer an irgendwann.

Ja, gut, was ist Plone? Plone ist ein Enterprise Web Content Management System.

Es ist glaube ich von den Systemen, die wir hier jetzt die Woche über gesehen haben, das einzige, was nicht auf PHP basiert.

Es baut auf Python auf. Es hat auch selber einen Applikations-Server unten drunter.

Das heißt, es läuft nicht im Apache oder in Nginx.

Soap als Applikations-Server unten drunter ist eher vergleichbar wie aus der Java-Welt, was wir aus Tomcat, Jetty oder so etwas kennen.

Plone ist ein volldynamisches System, was auch Hybrid-Ansätze hat.